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Apflftndments the Drawings 
Fig. 9B is amended to properly align the bracket at reference number 910 to surround 
only the <^wf^lssociation.associationEnds>' , element, thus aligning the figure with its 
corresponding text on p. 19, line 9. No new matter is introduced with this amendment 
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Claims 1,5, 7, 10 -11, 14, and 18 have been amended. No new matter is added with 
these amendments, which are supported in the specification as originally filed. Claims 1,5-7, 
10- 11, and 14-18 remain in the application. 

L proposed Correction to the Drawings 

A proposed replacement drawing is submitted herewith for Fig. 9B. The correction made 
in this replacement drawing is discussed above in "Amendments to the Drawings". No new 
matter is introduced with the replacement drawing. 

n. Re jection Under 35 U.S.C. S102flrt 

Paragraph 5 of the Office Action dated June 14, 2005 (hereinafter, "the Office Action") 
states that Claims 1 , 6 - 7, and 1 1 are rejected under 35 U-S.C. §102(b) as being anticipated by ' 
Rubin (U. S. Patent 5,412,797). This rejection is respectfully traversed. 

Rubin has no teaching of "programrnatically determining" the multiplicity of an existing 
association end, to which the first limitation of Applicant's independent claims is directed. It is 
not enough to cite reference numbers of objects that can be construed as members of one-to- 
many or one-to-one relationships, as has been done in the Office Action (see Page 6, first 
buUeted item discussing Claim 1). The text ched in the Office Action for "evaluating" has 
nnthinptodn with determining multiplicity. Instead, the text in col. 1 1, lines 59 - 64 pertains to 
determining whether or not a one-to-many relationship is empty- This is indicated by the 
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operation's name, "an gfflBtX query- (col- H, Hne 59, emphasis added), and its description 
"whether a given source instance presents any, sink instances" (col- 11, lines 60 - 6L, emphasis 
added). 

Thus, the Office Action fails to provide a proper reference that teaches this first limitation 
of Applicants' independent claims. 

Furthermore, Applicants' independent Claims 1, 7, and 1 1 have been amended herein to 
more clearly specify limitations of their invention. In particular, Claim 1 (for example) specifies 
"evaluating a request to modify an existing association end of a bi-directional link" (lines 3-4, 
emphasis added) and specifies a particular ordering of steps to be taken if the association end has 
"single multiplicity" (lines 7 - 16) and if the association end has "many multiplicity'' (lines 17 - 
24). That is, the ordering of the three limitations for each case is indicated as "first* (line 9 or 
19), "next" (line 11 or 21), and "then" (line 1 5 or 23). Independent Claims 7 and 1 1 are similar. 

Rubin does not teach modifying association ends m this manner. Rubin teaches creating 
an initial relationship between two newly-created instances at coL 9, line 49 - col. 10, line 23 
(corresponding to Fig. 8). As disclosed therein, a "source pointer" 46 of an "isPresentedBy" 
relation of a sink instance 28 is set to point to a source instance 26 (col. 9, lines 55 -> 59; step 86 
of Fig. 8) and the sink instance 28 is then inserted into a ring of sink instances (col. 9, lines 59 - 
61; step 88 of Fig. 8). More details of Ihe insertion into the ring are then provided, specifying 
that the new sink instance 28 has its "next sink" pointer 42 set (col. 9, lines 66 - 68; step 90 of 
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Fig. 8) and its "previous sink" pointer 44 set (col. 10, lines 1 - 5; step 92 of Fig. 8). A 
previously^xisting sink instance in the ring of sink instances then has its "next sink" pointer 42 
set to point to the newly-inserted sink instance 28 (col. 10, lines 6 - 1 8 ; step 94 of Fig. 8), and me 
"last sink" pointer 38 in the source instance is set to point to the newly-inserted sink instance 28 
(col. 10, lines 19 - 23; step 96 of Fig- 8). 

This disclosed approach of denning (or "inserting", to use Rubin's term; see col. 9, line 
50) a new relationship is paterrtabry distinct from Applicants' disclosed technique of modifyin g 
an existing association end. First, adding a ngw. relationship (as in Rubin) is different from 
modifying an existing association end (as claimed by Applicants). Furthermore, the particular, 
ordered steps specified in Applicants 7 independent claims cannot be aligned to the above-cited 
teachings from coL 9, line 49 - coL 11, line 23 of Rubin, which discloses modifying a pointer in a 
source instance and modifying several pointers in sink instances: it is not enough to find 
references in Rubin to source and sink instances and relations between them. Instead, Applicants 
are entitled to have all words of their claim language considered in judging the patentability of 
their claimed invention, including the ordering terms of "first", "next", and "then". (See Section 
2143.03 of the MPEP, "All Claim Limitations Must Be Taught or Suggested", which makes 
reference to In re Wilson, 165 USPQ 494, 496 (C.C.P.A. 1970), which stated "All words in a 
claim must be considered in judging the patentability of that claim against the prior art 4 *.) 

Rubin also teaches a "remove" operation whereby an existing sink instance can be 
removed from the one-to-many relationship of a particular source instance. This is described in 
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col. 10, line 33 - 55 (corresponding to Fig. 9). As described therein, the source pointer 46 of the 
sink instance 28 is first set to null (col. 1 0. lines 40 - 41 ; step 102 of Fig. 9), and the sink instance 
is then removed fiom the ring of sink instances (col. 10, lines 43 - 45; step 104 of Fig. 9). To 
remove the sink instance from the ring, the next sink pointer 42 and previous sink pointer 44 of 
the neighboring sink instances are reset to point to the addresses where the removed sink 
instance's pointers were pointing (col. 10, lines 47 - 55; steps 106 and 108 of Fig. 9). 
Applicants' claimed invention does not pertain to removing sink instances. 

Rubin further teaches a technique for "swapping" a sink instance which is related to one 
source instance, instead making the sink instance related to a different source instance. See col. 
1 1 , lines 7-15, Referring now to Applicants* specification, an example scenario is described 
therein where an employee "John" is moved from a "Shoes" department to a "Clothing** 
department If the employee object for "John" is a sink instance and the department objects for 
"Shoes" and "Clothing*' are source instances, men this "swap" operation discussed in Rubin is 
similar to the example scenario for moving John to the Clothing department To modify the 
existing "department" association end in the example scenario, which has a "single" multiplicity 
(see reference numbers 210 and 230 in Applicants' Fig. 2), Applicants' claim limitations specify 
first discofln ect OTff the previously-existing inverse association end (i.e., the "employees" 
association end that points from the "Shoes" department to the employee "John"); np xt setting an 
inverse association end to reflect an inverse association (i.e., the "employees" association end is 
now pointing from the "Clothing" department to the employee "John"); and thenjsejjjfag the 
requested association end (i.e., the "department" association end is set to point from employee 
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"John" io department "Clothing'*, indicating that John's current department is Clothing). 

By contrast, Rubin teaches that the swap operation "is similar to the insert and remove 
operations described above, except that swap may be fester than remove followed by mS3CL since 
STEP 102 of the remove operation [where the "source" pointer in the sink instance is set to null] 
does not need to be performed" (col. 11, lines 10-15, emphasis added). In other words, Rubin 
teaches swapping by performing a remove ~ except for Step 102 - and then performing an 
Insert. According to the teachings in Rubin, the remove operation (with Step 102 omitted) 
comprises resetting "next sink" and "previous sink" pointers in sink instances (see Fig. 9 and the 
above discussion of its corresponding text in col. 10); this has no correlation, to Applicants' 
claimed technique. Referring to the "single" multiplicity example discussed above, Rubin's 
Insert operation then would ( 1 ) set a source pointer for the employee "John" object to point to the 
department "Clothing" object (as per Step 86 of Fig. 8); (2) set "next sink" and "previous sink" 
pointers (as per Steps 90-94 of Fig. 8), which have no correlation to Applicants' claimed 
invention; and (3) set a "last sink" pointer of the "Clothing" object to point to the "John" 
employee object (as per Step 96 of Fig. 8). 

As can be seen by this comparison, the order of steps taken when using Rubin's technique 
is tfiflfe rentfrnm the order of steps specified for "single multiplicity" association ends in 
Applicants' claim language. 

Furthermore, Applicants' claim language specifies vet another order of operations if the 
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association end to be modified has "many multiplicity". For example, if the "employees" end of 
an association is to be modified (see reference numbers 220 and 235 of Fig. 2 in Applicants' 
specification), then this is a "many" multiplicity scenario. In contrast to Applicant's claim 
language (see Claim 1, lines 7 - 16 and lines 17 - 24), Rubin has no teaching of using an 
alternative ordering (or any different steps) depending on whether an association end has single 
or many multiplicity. Instead, a single approach (discussed above with reference to Fig. 8) is 
described for inserting relationships, and modification thereof is described comprising a sjagl§ 
approach (discussed above with reference to col. U, lines 7 - 1 5) for swapping relationships, 
without regard to single/many multiplicity of an end to be modified. 

Applicants wish to clarify a point raised on Page 4 of the Office Action, final paragraph, 
which states 

It is submitted that this characterization of Rubin's teaching contradicts 
with Applicants' assertion that "Rubin's one-to-tnany relationships have both 
single and many multiplicity" 

(emphasis original), referring to Page 12 of Applicants' previous response submitted on February 

22,2005. This is an incorrect characterization of Applicants' response. The quoted text does 

appear in Applicants' previous response, but it is referring to a statement in the pyevfous Office, 

Action (dated December 22, 2004; see the reference in Applicants' previous response to p. 4, 

lines 9-10 of the December, 2004 Office Action, and Applicants' introductory text "As stated 

therein ..."). Thus, it is the Office Action that states this assertion, not Applicants. (And, in fact, 

a one-to-many relationship does oat have both of these multiplicities. Rubin's "presents" 

relationship is one-to-many, and thus has "many" multiplicity. Rubin's inverse relationship, 
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-isPresentedBy", is one-to-one, and has "single" multiplicity; see coL 6, lines 34-35, stating 
"Inversely, one sink instance 28 isjasserjteto. at most, one source instance 26.% emphasis 
added.) 

In view of the above, Applicants respectfully submit that their independent Claims 1, 7, 
and liar© patentable over Rubin. Dependent Claim 6 is therefore deemed patentable over Rubi 
as welL Accordingly, Applicants respectfully request that the Examiner withdraw the §102 

rejection. 

HI. Rejection Under 35 H.S.C. 8103(al 

Paragraph 7 of the Office Action states that Claims 5, 10, and 14 are rejected under 
35 U.S.C. § 103(a) as being unpatentable over Rubin in view of Johnson (a publication from 
javaworid.com). Paragraph 8 of the Office Action states that Claims 1 5 - 18 are rejected under 
35 U.S.C. § 103(a) as being unpatentable over Rubin in view of Lindberg et al. (U. S. Patent 
Publication 2003/0028540). These rejections are respectfully traversed 



As demonstrated above, Rubin tails to render Applicants' independent Claims 1, 7, and 
1 1 unpatentable. Rubin therefore cannot be combined with Johnson or Lindberg (assuming, 
arguendo, that one of skill in the art would be motivated to attempt such combination and that 
such combination can, in met, be made) to render Applicants' dependent Claims 5, 10, and 14 - 
18 obvious. Accordingly, Applicants respectfully request that the Examiner withdraw the §103 
rejection. 
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IV. Conclusion 

Applicants respectfully request reconsideration of the pending rejected claims, 
withdrawal of all presently outstanding rejections, and allowance of all remaining claims at an 
early date. 

Respectfully submitted* 



Marcia L. Doubet 
Attorney for Applicants 
Reg. No. 40,999 
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